There are many options for Website Hosting. Organizations may host their websites and other applications using their own servers located on the organizations' property as well as in infrastructure providers' data centers Infrastructure providers frequently choose to offer virtual servers to their customers (a subscribing organization, or simply a subscriber), instead of physical servers. A virtualization host (vHost), or hypervisor, controlled by the staff of the infrastructure provider allows subscribers to set up many virtual machine instances (VMs) on a single physical server. The number of virtual machines in use by a subscriber can vary over time as demand fluctuates.
There are a number of outsourced infrastructure service providers that offer these kinds of cloud computing services to their subscribers. Cloud computing provides convenient, on-demand access to a shared pool of configurable computing resources (networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service-provider interaction. Using various software tools, a subscriber can provision resources from the shared pool automatically without action by the staff of the cloud computing provider. The cloud computing resources are pooled and shared among all subscribers with resources dynamically re-assigned according to end-user demand. Resources are often located in many different remote geographical locations.
The cloud computing resources can be rapidly provisioned to meet demand surges, allowing the subscribers' resources to be scaled up and down as demand fluctuates. Such resource usage is monitored and reported so that subscribers may be billed only for actual usage.
Software as a Service (SaaS) is an application delivery model that enables organizations to subscribe to software application services running at the SaaS provider. These SaaS applications can be accessed across the Internet through web browsers or other clients. The subscriber does not control the underlying servers, storage, network, or operating systems. Some outsourced infrastructure providers such as those that offer on-demand cloud computing services have built infrastructure control applications and application program interfaces (APIs) that enable subscribers to interact with their infrastructure in a manner similar to that of SaaS applications. These kinds of outsourced infrastructure providers are often referred to as an Infrastructure as a Service (IaaS) provider. Examples of IaaS providers include Amazon, Linode, and Rackspace, and examples of their products include Amazon's Web Services Elastic Compute Cloud (EC2), Linode, and Rackspace Cloud Hosting.
Many organizations, as they begin to take advantage of IaaS offerings, may use a hybrid approach. The organization may have company-owned on-premises servers and also subscribe to one or more cloud computing IaaS providers. The organization may use a combination of physical and virtual servers, both on-premises and off-premises.
Data may need to be transferred between on-premises servers and off-premises servers. These servers could be either physical or virtual. Such hybrid clouds pose various challenges, especially for networking, since the cloud service provider still controls their underlying hardware infrastructure such as the servers and networks. The subscriber does not control the underlying hardware or networks at the cloud service provider.
FIG. 1 shows a prior-art hybrid cloud network. An organization such as a company that has a web site or application that they wish to deploy in the cloud, has company-owned servers located on company property at on-premises location 104. The on-premises servers can include some dedicated servers that are physical machines, such as physical node 12, and other dedicated servers that run a virtualization host (vHost or hypervisor) software, such as VMWare or Xen, originally developed by the University of Cambridge Computer Laboratory. The virtualization host software runs several virtual-machine nodes, VM nodes 14, which can each run applications to service client requests from Internet 100.
The organization also rents dedicated physical servers at hosted-server location 106 to run applications that service user requests from Internet 100. These servers include hosted physical nodes 13, which can be hosted by hosted server providers such as RackSpace. Other services could be provided by hosted-server location 106 such as cloud services (not shown) or co-location servers that are owned by the organization, not the provider.
The organization also subscribes to an IaaS provider which offers cloud computing resources from cloud-computing provider 108. Cloud-computing provider 108 could be EC2 or Rackspace Cloud, Linode, Slicehost, Terramark or any other similar IaaS provider. Cloud-computing provider 108 provides cloud services on-demand by running IaaS software that allows subscribers to automatically provision virtual machines instances such as VM nodes 14.
Client applications such as web browsers of remote users from Internet 100 can access the nodes that are configured as webservers, while the rest of the nodes can communicate with each other to process application data or serve database requests as needed. For example, a webserver application running on VM node 14 on cloud-computing provider 108 may need to communicate with a database application running on VM node 14 at on-premises location 104. Another webserver application running on hosted physical node 13 at hosted-server location 106 may also need to communicate with a database application running on physical node 12 at on-premises location 104.
IP Packets are sent over Internet 100 using Internet Protocol (IP) addresses and layer-3 routing of IP packets. Routers 22 transfer packets to and from local networks at on-premises location 104, hosted-server location 106, and cloud-computing provider 108. These local networks are usually layer-2 Ethernet networks that use Media-Access-Controller (MAC) addresses, sometimes referred to as Ethernet addresses. For example, layer-2 physical network 20 is a Local-Area-Network (LAN) that connects network interface controllers (NIC) 18 and router 22. The virtualization host may provision virtual NIC VNIC 16 for each virtual machine VM node 14, and connect each VNIC 16 to a physical NIC 18 for the virtual servers.
Cloud-computing provider 108 may have internal network 102 that uses router 22 to connect its own systems and possibly other datacenters to Internet 100. Internal network 102 could be a combination of wide area network (WAN) links connecting geographically distributed datacenters as well as LANs. Internal network 102 also includes the physical NICs on the IaaS host (not shown) that are necessary to connect VNIC 16 for instances of VM nodes 14 running on the IaaS host to an internal LAN connected to router 22 and provide access to Internet 100. Internal network 102 could be part of the IaaS provider's own network or even part of a different network provider's network for wide area connectivity such as Level 3 or AT&T.
The implementation details of internal network 102 are unknown to subscribers and therefore could use any combination of layer 3 routing and layer 2 switching technologies. Subscribers to cloud service provider 108 have no control over internal network 102 and therefore cannot change the configuration in any way.
Sometimes data needs to be transferred among servers at different locations. For example, an organization may keep its customer database secure at on-premises location 104 and only allow queries into the database from applications running on external servers such as at hosted-server location 106 or cloud-computing provider 108. Data may need to be transferred from physical node 12 to hosted physical node 13. A dedicated trunk connection may not be cost effective or practical between on-premises location 104 and hosted-server location 106, so a virtual-private-network (VPN) can be established through Internet 100.
VPN tunnel 24 connects physical node 12 to hosted physical node 13 by establishing a tunnel through Internet 100. Application software running on physical node 12 sends a message to hosted physical node 13 using a virtual IP address for hosted physical node 13. VPN software encrypts and packages the message and translates the virtual IP address to a physical IP address of NIC 18 on hosted physical node 13. VPN software on hosted physical node 13 translates the physical IP addresses to virtual IP addresses and decrypts the message. VPN tunnel 24 can also send messages in the reverse direction by a similar process.
While effective, VPN tunnel 24 only connects two nodes in a point-to-point manner. Separate VPN tunnels need to be set up for each pair of nodes. Thus a large number of VPN tunnels 24, 25 may need to be configured, one for each pair of nodes. This configuration may be manual and time-consuming.
As additional instances of VM nodes 14 on cloud-computing provider 108 are created, additional VPN tunnels 25 may need to be set up manually if applications running on VM nodes 14 need to query databases on physical node 12 at on-premises location 104, as well as to every other node with which it needs to communicate. Each VPN tunnel 25 connects a VNIC 16 for one of VM nodes 14 to NIC 18 of physical node 12.
The administrative burden of creating these VPN tunnels causes some organizations to introduce a dedicated VPN gateway device whereby each node connects only to the gateway device, thereby simplifying VPN creation. However, this gateway device introduces additional latency as well as a potential performance bottleneck since the gateway needs to process all packets from all nodes. The hub and spoke topology required for these kinds of VPN tunnels precludes the use of specific network topologies that may be required for certain multi-tiered application deployment.
Even without a gateway device, fully meshed VPNs can sometimes impact performance. VPN software is often simply a user-level application, which needs to translate individual network packets and encrypt data, which can easily slow a system down.
Virtual Layer-2 Networking in Parent Application
Rather than use layer-3 IP routing through VPN tunnels 24, 25, the parent application discloses that additional VM nodes 14 on cloud-computing provider 108 and at hosted server location 106 appear to be on a virtualized layer-2 network at on-premises location 104. Switching over layer-2 physical network 20 is performed by MAC (or Ethernet) addresses at layer-2, rather than IP addresses at layer-3.
Connections to VM nodes 14 on cloud-computing provider 108 and at hosted server location 106 are virtualized and appear on a virtualized layer-2 network that includes layer-2 physical network 20 at on-premises location 104. This is better than networking using only VPN tunnels, which are hard to maintain, restrict network topologies, and often introduce performance bottlenecks.
FIG. 2 shows a hybrid cloud network with overlaid user-configurable virtual layer-2 networks. Virtual networks VN1, VN2, and VN3 are overlaid on top of the physical layer-3 (IP) and layer-2 LAN (Ethernet) networks that physically connect on-premises location 104, hosted-server location 106, and cloud-computing provider 108. Virtual networks VN1, VN2, and VN3 are isolated from each other, yet use the same underlying physical networks.
Virtual networks VN1, VN2, and VN3 are layer-2 networks, using virtual Ethernet addresses to identify nodes on the virtual network. Since virtual networks VN1, VN2, and VN3 are isolated from each other, they each can use their own independent IP and Ethernet addresses ranges. This means that the same virtual IP and Ethernet addresses can exist on two different VNs without conflict, since the virtual IP and MAC addresses are specific only to one virtual network.
Virtual network VN1 connects physical node 12 and VM nodes 14 on on-premises location 104 to VM nodes 14 on cloud-computing provider 108. An organization could use this virtual network VN1 to run applications that can access an internal database on physical node 12, such as for remote employees and other trusted end-users.
Virtual network VN2 connects hosted physical nodes 13 on hosted-server location 106 to VM nodes 14 on cloud-computing provider 108. VN2 does not allow remote applications on VN2 to access physical node 12 on on-premises location 104. An organization could use this second virtual network VN2 to run applications that cannot access an internal database on physical node 12, such as for the general public accessing a company web site, or other un-trusted end-users.
Virtual network VN3 connects hosted physical nodes 13 at hosted-server location 106 and VM nodes 14 on on-premises location 104 but not VM nodes 14 on cloud-computing provider 108. An organization could use this third virtual network VN3 to run applications that can access another, less secure internal database on VM nodes 14, such as for the general public querying a database of products and prices that is kept on VM nodes 14 on on-premises location 104.
Each of virtual networks VN1, VN2, and VN3 has a different group of virtual Ethernet addresses within that network's broadcast domain. The same virtual Ethernet (or virtual IP) address could exist on two virtual networks, such as by being part of broadcast domain B1 of VN1 and broadcast domain B2 of VN2. Virtual networking software isolates each virtual network from other virtual networks.
Other organizations (not shown) could have other virtual networks that also use servers at hosted-server location 106 and cloud-computing provider 108, along with company servers at their own, different on-premises location (not shown). These virtual networks are kept isolated and independent of other virtual networks by virtual networking control software.
Special virtual-network configuration software is used to manage and control each VN. Providers of this configuration software can make it available to subscribers offering it as a compliment to their existing on-premises networks, rented physical servers, and cloud computing provider subscriptions. This virtual-network configuration and management service is itself an Infrastructure as a Service offering. Unlike Amazon's EC2 IaaS offering, this virtual network IaaS need not provide compute or storage resources, only network infrastructure configuration and management services on demand.
Organizations can subscribe to this virtual network offering, and configure and manage their own virtual networks using special virtual-network configuration software. A subscriber organization can add or remove nodes on a virtual network without help by the staff at cloud-computing provider 108 or hosted-server location 106. Thus the subscribers have control over their own virtual networks. The virtual layer-2 networks become another resource that is user-configurable and metered that can be provided by an independent Virtual Network Infrastructure as a Service (VN IaaS) provider or as a virtual network subscription offering made available by cloud-computing provider 108.
IT staff at on-premises location 104 now has control over the virtual network that connects all of their systems, without requiring control over the network that the external systems are physically attached to.
When one of the instances of VM nodes 14 moves from one physical server (virtualization host) to another at cloud-computing provider 108, such as when node migration occurs due to guest migration, the virtual-network configuration and network policies may move with the instance or guest as its is moved.
Isolation of Multiple Virtual Networks—FIG. 3
FIG. 3 shows multiple virtual networks that are isolated form one another. A large organization has two separate virtual networks 320, 322. Virtual network 320 (VN1) has virtual MAC addresses that are in broadcast domain B1, and connects to physical node 302 and VM nodes 304, 306 at on-premises location 104 and to VM nodes 308, 310 at cloud-computing provider 108.
A second virtual network 322 (VN2) has virtual MAC addresses that are in broadcast domain B2, and connects to physical nodes 312, 314 and to VM nodes 316, 318 at cloud-computing provider 108.
Virtual networks VN1, VN2 behave as though their nodes were connected using a familiar physical layer-2 switch. However, in reality, they are connected via a distributed virtual layer-2 switch that forwards Ethernet frames to the correct destination using the underlying physical network, such as router 22 and Internet 100.
Virtual-network-configuration clients 54 allow VN IaaS subscribers to configure each of virtual networks VN1, VN2 independently from each other as well as from the internet and the physical network provided by cloud-computing provider 108 to their subscribers.
While such virtual layer-2 networks are useful, sometimes data may need to be sent from virtual network VN1 to second virtual network VN2. Since virtual networks 320, 322 are isolated from each other, and virtual, they are not visible to one another. While a single larger layer-2 virtual network could be used that connects to all nodes, there may be reasons for a single organization to have two or more separate layer-2 virtual networks. For example, one virtual network VN1 may be used for external sales support, while another virtual network VN2 is used for back-end office functions such as accounting.
It would be desirable to maintain two or more layer-2 virtual networks that are separate from each other, but still provide a virtual mechanism to pass data from one virtual network to another virtual network. The parent application provided virtual layer-2 networks. It is desirable to provide layer-3 virtual routing to connect two or more layer-2 virtual networks. A virtual router for use with virtual networks is desirable.
Virtual layer-2 and virtual layer-3 networking software for use by a cloud computing subscriber is desired to extend Infrastructure as a Service (IaaS) to multiple virtual layer-2 networks. This allows a subscriber to configure their own layer-2 networks, and connect them together with a virtual layer-3 router. An IaaS userconfigurable virtual network is desirable for virtual layer-3 routing.